1. Field of the Invention
The invention relates generally to storage subsystems and more specifically relates to techniques for initializing a new logical unit as a background process substantially overlapped with host I/O request processing on the new logical unit.
2. Discussion of Related Art
As complexity of computing applications has evolved so to have demands for reliability and speed in associated storage subsystems. In general, computing storage subsystems are used for storage and retrieval of programs and data associated with operation of various programs. The mission critical nature of some applications has led to corresponding demands for increased reliability in storage subsystems. Further, high-performance storage related applications, such as multimedia data capture and replay, have contributed to increased demands for performance on storage subsystems.
RAID storage management techniques (Redundant Array of Independent Disks) have been employed for some time to enhance both performance and reliability in such high-performance, high reliability storage applications. Striping techniques applied within RAID storage management distribute stored data over multiple independent disk drives thereby enhancing storage performance by distributing storage and retrieval operations over a plurality of disk drives operable in parallel. Redundancy techniques employed within RAID storage subsystems enhance reliability of the storage subsystem by generating and maintaining redundancy information associated with the user supplied data. The redundancy information ensures that failure of any single disk drive does not risk loss of data and, in some cases, allows the RAID storage subsystem to continue operation (though often in a degraded mode).
RAID storage management encompasses a number of storage management techniques for distributing data (striping) and for generating, maintaining, and distributing redundancy information over a plurality of drives. Each of these RAID management techniques is typically referred to as a “level” such as RAID level 0, RAID level 1, RAID level 5, etc. One common RAID storage management technique, often referred to as RAID level 5, distributes user data over a plurality of drives and associates therewith an additional portion of data (redundancy information) generated by use of XOR parity operations. A stripe of data consists of distributed portions of user data and the associated redundancy information. A volume or logical unit (LUN) comprises a plurality of such stripes distributed over a subset of disk drives in the storage subsystem.
Typically a RAID controller, often integrated within the storage subsystem, applies RAID storage management techniques to store and retrieve such stripes on the disk drives of the storage subsystem. The RAID storage controller hides from the host systems information relating to the specific locations of individual portions of data and hides information regarding generation and maintenance of the required redundancy information. To an attached host computing system, the RAID storage controller makes a volume or logical unit appear essentially as a single, highly reliable, high-performance, high-capacity disk drive. In general, the RAID storage controller provides a mapping function from logical addresses or locations specified in host I/O requests to physical storage locations corresponding to the striped information distributed over multiple disks.
In RAID level 5 storage management (as well as other forms of RAID storage management such as RAID levels 6) it is important that a newly defined storage volume be made “XOR consistent”. XOR consistency as used herein refers to the state of each stripe such that the data in the stripe and the associated redundancy information are consistent—i.e., the parity information corresponds to the associated data of the stripe. While RAID level 5 uses XOR parity, “XOR consistent” as used herein refers to any redundancy information stored in the array of disk drives that make up a volume. For example, XOR consistent may also refer to the redundancy information used in RAID level 6 and the mirrored redundancy information used in RAID level 1. Therefore, although the problems presented herein are discussed in detail with respect to RAID level 5, similar problems are encountered in other RAID management levels where a new volume must be initialized to make the redundant information ready for use.
When a new volume is defined by allocating portions of storage capacity distributed over a plurality of drives, the volume may initially include random data leftover from previous utilization of the disk drives or generated from some other source. In general, the initial information on a newly defined storage volume will not be XOR consistent.
A common technique applied to assure XOR consistency in a newly defined RAID level 5 volume is to read every block of data in a stripe, compute a corresponding XOR parity block, and write the newly computed XOR parity block to the appropriate location for the redundancy information of the stripe. Though data of the stripe may be meaningless (i.e., leftover) the stripe will then be XOR consistent. Such a process can be very time-consuming where the newly defined RAID level 5 volume is particularly large. Typically during such an initialization process, the RAID storage controller makes the volume (logical unit) unavailable for storage or retrieval of information by an attached host system. Frequently, such an extended delay in availability of the new volume is unacceptable.
Another prior technique described in the '023 patent allows I/O requests to be processed during initialization of a newly defined RAID level 5 volume. As the initialization process proceeds, a threshold indicator tracks its progress. If a host I/O request uses stripes that fall below the progress threshold, the request is handled normally. I/O requests are requeued for later processing by the controller if any part of the request involves uninitialized portions of the new volume. This prior technique allows the logical unit to be referenced by an attached host systems but defers the actual I/O operations until appropriate portions of the newly defined logical unit have been initialized (i.e., made XOR consistent).
A similar problem is addressed in the '384 application where a logical unit is migrated to another logical unit. The methods and structures discussed therein permit I/O operations to proceed substantially in parallel with the data copying operation.
It is evident from the above discussion that an ongoing problem exists in making a newly defined RAID volume available for host I/O request processing as soon as possible.